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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document specifies the architecture and functions of an IPTV system that makes use of the NGN IMS 
architecture and its features, implementing the requirements defined in TS 181 014 [14] and TS 181 016 [15]. 

The present document has taken IPTV solutions defined by other organizations (such as DVB, ATIS IIF, etc.) into 
account. It is based on an IMS based architecture and where appropriate the aforementioned solutions are referenced. 

By relying on common components the resulting architecture can coexist with other TISPAN NGN services. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI TS 182 006 (VI. 1.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description 
(3GPP TS 23.228 v7.2.0, modified)". 

[3] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment 
Sub-System (NASS)". 

[4] ETSI TS 133 220: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Generic Authentication Architecture (GAA); Generic 
bootstrapping architecture (3GPP TS 33.220)". 

[5] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[6] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[7] ITU-T Recommendation P. 10/G. 100: "Vocabulary for performance and quality of 

service - Amendment 2: New definitions for inclusion in Recommendation P. 10/G. 100". 
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[8] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); 
Functional Architecture". 

[9] ETSI TS 183 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion 
(CDIV); Protocol specification". 

[10] ETSI TS 182 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Presence Service; Architecture and functional description 
(Endorsement of 3GPP TS 23.141 and OMA-AD-Presence-SIMPLE-Vl-0)". 

[11] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[12] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 
(3GPP TS 23.228 version 7.9.0 Release 7)". 

[13] ETSI ES 283 030: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Presence Service Capability; Protocol Specification 
[3GPP TS 24.141 V7.0.0, modified and OMA-TS-Presence-SIMPLE-Vl-0, modified]". 

[14] ETSI TS 181 014: '"Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements for network transport capabilities to support 
IPTV services". 

[15] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] DSL Forum Technical Report TR-126: "Triple-play Services Quality of Experience (QoE) 

Requirements". 

[i.2] ETSI ES 282 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Charging management [Endorsement of 3GPP TS 32.240 
Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPPTS 32.298 Release 7 and 
3GPP TS 32.299 Release 7, modified]". 

[i.3] ETSI TR 182 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Organization of user data". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

offset: value indicating the elapsed time between the beginning of content and the current reading position of the 
reading cursor in that same streamed content 

park TV: feature that would enable a user (on a UE) make an impulsive request to record ongoing BC 
service/programme from a particular point in time 

NOTE: This recording point is also referred to as a bookmark. 
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park and pickup TV: feature that would enable a user (on a UE) to Park TV and subsequently Pickup TV 

pickup TV: feature that would enable a user (on a UE) retrieve or request BC service/programme that was recorded and 
bookmarked via an impulsive record request 

NOTE: The IPTV content can be retrieved from the bookmarked location or recording point on same or different 
UE at a later point in time. 

programme: entry in the Electronic Programme Guide (EPG) 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

ATIS Alliance for Telecommunications Industry Solutions 

BC Broadcast 

CD Compact Disc 

CDR Call Data Record 

CLE Connectivity session Location and repository Function 

CoD Content on Demand 

CSCF Call Session Control Function 

DVB Digital Video Broadcast 

DVD Digital Versatile Disc 

ECF Elementary Control Function 

EFF Elementary Forwarding Function 

EPG Electronic Programme Guide 

GAA Generic Authentication Architecture 

GBA Generic Bootstrapping Architecture 

GUI Graphical User Interface 

GUP Generic User Profile 

HD High Definition 

HNED Home Network End Device 

HTML HyperText Markup Language 

ID IDentifier 

IIF IPTV Interoperability Forum 

IMPU IMS Public User identity 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IPTV IP Television 

ISC IMS Service Control 

ISDN Integrated Services Digital Network 

MCE Media Control Function 

MDF Media Delivery Function 

MF Media Function 

NASS Network Attachment Subsystem 

NGN Next Generation Network 

N-PVR Network-Personal Video Recorder 

P-CSCF Proxy CSCF 

PSTN Public Switched Telecommunication Network 

PVR Personal Video Recorder 

QoE Quality of Experience 

QoS Quality of Service 

RACS Resource and Admission Control Subsystem 

SCF Service Control Function 

S-CSCF Serving CSCF 

SD Standard Definition 

SDF Service Discovery Function 

SIP Session Initiation Protocol 

SLF Subscription Locator Function 

SSF Service Selection Function 

TV Television 
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UE User Equipment 

UPSF User Profile Server Function 

URI Uniform Resource Identifier 

XCAP XML Configuration Access Protocol 

XDMS XML Document Management Server 

XML Extensible Markup Language 



High-level overview 
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Figure 1 : High level functional architecture for IMS-based IPTV 

NOTE 1 : The specification of management functions and content provider functions is considered out of scope of 
the present document. 

User equipment: 

UE: The IPTV enabled UE terminates the IPTV control and media signals, and displays the corresponding information 
to the user. The UE interaction with the user allows selection of programme, content, and service descriptions, such as 
content guides for broadcast and CoD services. 

Application functions and IPTV service functions: 

Enables operation of or provides IPTV services. This includes IPTV Service Supporting Functions. 

IPTV Service Supporting Function: The IPTV Service Supporting Function defined here are those common functions 
which could support or be used by other IPTV service or applications. 
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NOTE 2: Examples of IPTV service supporting functions may be Service Discovery and Selection functions. 

User Profiles: 

User Profiles includes user data that are involved in providing IPTV services. 

Core IMS: 

It provides functionality for authentication, authorization, and signalling for the setup of the service provisioning and 
content delivery. It routes signalling messages to the appropriate application server or triggers the applications based on 
settings maintained in the UPSF. For resource reservation and admission control this function interacts with the RACS. 

Transport Functions: 

Transport Control: contains functions from RACS and NASS. It provides policy control, resource reservation and 
admission control as well as IP address provisioning, network level user authentication and access network 
configuration as defined in TISPAN. 

Transport Processing Functions: represents network access links and IP core. The IP core is in charge of data 
transmission with quality of service support. 

Media Delivery, Distribution and Storage: 

The Media Delivery, Distribution and storage function receives and stores live feeds and media streams coming into the 
IPTV System from Content Providers. It is mainly in charge of media processing, delivery, storing, trans-coding and 
relaying. This function performs all these tasks along with the control of - or feedback to the IPTV Service and Control. 
Content protection may also be performed here or already protected content could be delivered over these 
functionalities. 

5 Overview of functional entities 

5.1 Functional architecture for IPTV services 
5.1 .1 Functional architecture overview 

The overall functional architecture for IPTV service is shown in figure 2. 
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Figure 2: Functional architecture for IPTV services 

NOTE 1: Only Xc and Xd are explicitly shown as traversing the Transport Processing Functions. For the sake of 
simplicity other reference points are only shown as end to end. 

In figure 2, the IPTV Service Control Functions, the IPTV Media Functions, the Service Selection Function (SSF) and 
the Service Discovery Function (SDF) fit in the context of TISPAN NGN Functional Architecture Release 2 [1]. 

NOTE 2: To support the regionalized delivery of content and metadata in accordance with applicable regulations, at 
least one of the service layer entities involved in the IPTV service should query the UE location from the 
NASS and enforce the regionalization. 

As stated in [2], the IMS architecture shall be based on the principle that the service control for Home subscribed 
services for a roaming subscriber is in the Home network. This principle shall be applied also in case the IPTV solution 
supports roaming. 

5.1.2 IPTV services 



5.1.2.1 



Content on Demand (CoD) 



The CoD (Content on Demand) is an IPTV service function which is split into a service control part (CoD-SCF), a 
media control part (CoD-MCF) and a media delivery function (CoD-MDF). The CoD-SCF exchanges messages with 
Core IMS. The service request/response messages between the UE and the CoD-SCF are transferred via the Core IMS. 
Media Control messages are exchanged between the UE and the CoD-MCF via the Xc reference point. Media Data is 
exchanged between UE and CoD-MDF via the Xd reference point. 
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5.1.2.2 Broadcast (BC) 



The BC (Broadcast) is a function which hosts Broadcast IPTV services and is spht into a Service Control part 
(BC-SCF), a Media Control part (BC-MCF) and a Media Delivery Function (BC-MDF). The BC-SCF exchanges 
messages with Core IMS. The service request / response messages between the UE and the BC-SCF are transferred via 
the Core IMS. Media Data is exchanged between UE and BC-MDF via the Xd reference point. 

5.1 .2.3 Network Personal Video Recorder (N-PVR) 

The N-PVR (Network-Personal Video Recorder Function) is a function which hosts IPTV N-PVR services and is split 
into a Service Control part (N-PVR-SCF), a Media Control part (N-PVR-MCF) and a Media Delivery Function 
(N-PVR-MDF). The N-PVR-SCF exchanges messages with Core IMS. The service request/response messages between 
the UE and the N-PVR-SCF are transferred via the Core IMS. Media Control messages are exchanged between the UE 
and the N-PVR-MCF via the Xc reference point. Media Data is exchanged between UE and N-PVR-MDF via the Xd 
reference point. 

5.1.3 Functional entities 

5.1 .3.1 Service Discovery and Selection Functions (SDF and SSF) 

The Service Discovery Function (SDF) and Service Selection Function (SSF) are functions which provide information 
necessary to the UE to select an IPTV service. 

Tasks of the SDF: 

• Generates and/or provides the service attachment information. 

• Provides personalized service discovery. 

The service attachment information consists of SSF addresses in the form of URIs and/or ip-addresses. 
Tasks of the SSF: 

• Provides the service selection information, e.g. a list of available services that the UE can then browse and 
select. The SSF may optionally generate this service selection information. It may also retrieve and forward 
the service selection information. 

Provides personalized service selection information and/or information needed to personalize the service 
selection. This must be delivered via unicast mode. (See note 1 regarding multicast options.) 

Provides non-personalized service selection data. This can be delivered via multicast or unicast mode. 

• Optionally provides service selection presentation information. This presentation information may be 
personalized when it is delivered over unicast mode. Optionally receives selection request from UE, e.g. an 
N-PVR content capture request as described in clause 8.5. 

NOTE 1 : The way the service selection information might be personalized when it is delivered via multicast mode 
is out of scope for this release. However, specified below is a non exhaustive list of high-level options to 
achieve such personalization: 

■ Using the SDF: when processing a request from a particular user/UE, the SDF could redirect the 
user/UE to specific multicast addresses/SSFs corresponding to the category to which the user 
belongs. This would imply that users/UEs are classified into specific categories. 

■ Using the SCF: UE could fetch IPTV user profile information in the form of BC Service ID listings 
from the SCF. This may be encoded as XML document(s) via the Ut reference point using 
XCAP-like mechanism or as HTML document with possibly embedded scripts to filter this service 
selection data. This IPTV user profile information may then be used to locally filter the service 
selection data that was previously delivered via multicast mode. 

NOTE 2: EPG is defined in TS 181 016 [15]. 
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For each IPTV service, the following data is provided: 



• An identifier associated to the IPTV service: this identifier is used by service control functions and media 
functions to identify the requested content when processing service initiation requests. In case of a CoD 
service, the identifier identifies exactly one content item. In case of a BC service, the BC identifier, which is 
the Service Package Id related to BC profile defined in clause 7.3, identifies a set of channels among which the 
user can switch. 

• Optionally the set of network parameters that may be required by the UE to activate a service (e.g. the extra 
information that may be needed by the UE to establish content delivery channels and content control 
channels). 

• User readable data related to the IPTV service. 

5.1 .3.2 IPTV Service Control Functions (SCF) 

Tasks of SCF: 

• Service authorization during session initiation and session modification, which includes checking IPTV users' 
profiles in order to allow or deny access to the service. 

• Credit limit and credit control (using the on-line charging systems ES 282 010 [i.2]). 

• Select the relevant IPTV media functions. 

The SCF is a SIP AppHcation Server (AS). 

An IPTV SCF belonging to an IMS network managed by another provider shall not have direct access to user profile 
data in the UPSF via the Sh reference point; it may however have access to user profile data by other means 
(e.g. Rg reference point to GUP), depending on the NGN operator's implementation and capabilities. 

The SCF may use the IPTV profile in order to customize the user experience. For instance, the list of subscribed BC TV 
Services could be used to filter the information sent to the UE. The User Equipment communicates with the IPTV 
Service Control Functions via the Core IMS for the purpose of session management, and may be using the Ut reference 
point for the purpose of service profile configuration. In the latter case, an authentication proxy may sit between the 
User Equipment and the SCF. 

5.1 .3.3 IPTV Media Control and Delivery Functions (MCF and MDF) 

IPTV Media Functions are in charge of controlling and delivering the media flows to the UE. They are split into Media 
Control Functions (MCF) and Media Delivery Functions (MDF). 

Tasks of Media Control Function (MCF): 

Handling media flow control of MDF. 

May manage the media processing of MDF. 

Monitoring the status of MDF. 

Managing interaction with the UE (e.g. trick mode commands). 

Handling interaction with the IPTV service control function SCF. 

Keeping an accurate view on status and content distribution related to the different MDFs that it controls. 

Selecting an MDF, in the case an MCF controls multiple MDFs different criteria, may be applicable (as 
described e.g. for CoD in clause 5.2). 

Selecting MF, return the selection result to SCF and Redirect sessions to the selected MF (e.g. in case the 
requested content is not available on this MF or for load balancing among MFs). 

Generate charging information, e.g. for end-user charging based on the viewed content. 
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Tasks of MDF: 

• Handling media flows delivery (for delivering multimedia services to user). 

• Status reporting to MCF (e.g. reporting on established IPTV media streams). 

• Store of media (e.g. CoD assets) and may also store some service information stored with media for IPTV 

services. 

• In particular, it may be used for storage for the most frequently accessed content or user specific content 

(e.g. recording PVR, Time-shift TV, BC service with Trick mode, user generated content) if the same tasks are 
not performed by UE. 

• May additionally process, encode or transcode (if required) media to different required media formats (e.g. TV 
resolution depending on terminals capabilities or user preferences). 

• May perform content protection functionalities (e.g. content encryption). 

• May support content ingestion of IPTV media. 

• For BC services MDF may act as source for multicast streams of BC media streams. 

• May collect QoE reports (e.g. from UE using Xd). 

NOTE: To enhance QoE evaluation quality, QoE reports may additionally be collected from other sources than 
the UE. However, this is beyond the scope of the present document. 

To support QoE, the UE may send QoE reports via Xd concerning the quality of the IPTV Media Data received. 

Each IPTV Service Control Function uses the ISC reference point to communicate with the NGN Core IMS. As stated 
in TS 123 228 [12] (endorsed by TS 182 006 [2]), an Application Server may originate requests to a destination without 
involving the S-CSCF. This capability should be used in case the SCF is to communicate with the media function 
without involving the core-IMS. 

Each corresponding IPTV Media Function communicates with the UE over Xc and Xd for Media Control and Media 
Delivery. For each service, the corresponding Media Control entities communicate with the UE on the Xc reference 
point and control the appropriate Media Data Delivery entities which send the Media Data to the UE on the Xd 
reference point. 

5.1.3.4 UPSF 

The UPSF holds the IMS user profile and possibly IPTV specific profile data (see clause 7). It communicates with 
IPTV Service Control Functions at the Sh reference points and with the Core IMS at the Cx reference point as defined 
in ES 282 007 [11]. When multiple instances of a UPSF exist, the Core IMS and the IPTV Service Control Functions 
may use the services of a Subscription Locator Function (SLF) to fetch the address of the UPSF. The SLF 
communicates with IPTV Service Control Functions at the Dh reference points and with the Core IMS at the Dx 
reference point as defined in ES 282 007 [11]. For the sake of simplicity the SLF and associated reference points are not 
shown on figure 2. 

NOTE: The IMS principle procedures, such as security, authentication process, are also considered to be applied 
to this IPTV functional architecture and the procedures, unless explicitly stated otherwise. 

5.1 .3.5 Transport processing functions 

IPTV services make use of generic transport processing functions defined in ES 282 001 [1]. 



5.1.4 Elementary functions 
5.1.4.1 Content security functions 

Content security elementary functions are described in clause 10.2. 
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5.2 Interactions between CoD Service Control function and 
CoD Media Functions 

The relationship between CoD Service Control Function (SCF) and CoD Media Function (MF), composed of Media 
Control Function and Media Delivery Function, is shown in figure 3. 



CoD-MF 




Figure 3: Relationship between CoD Service Control Function and CoD Media Functions 

The specific CoD-MF for a particular session will be determined during the session initiation and resource allocation 
procedure. This determination may be based on the following criteria: 

• Location of the UE. 

• Status information of all the available media functions (e.g. online or offline, media processing capability, 
available resources in the different CoD-MF holding the same contents, etc.). 

• Load of the different CoD-MF holding the same contents. 

• Content identity of the requested content; It is recommended that the structure of the content identifiers be 
designed so as to facilitate this selection, without requiring parsing the full identifier. 

The selection process relies on elementary functions that can be hosted in an SCF and/or an MCF. In the latter case the 
MCF may act as a redirect server to redirect sessions to another MCF. And in some cases, the selection task of SCF 
and/or MCF may become very simple. E.g. if a Request-URI for service/content identifier corresponds to just one MCF, 
then SCF and/or MCF may just transfer the session to the unique MCF. 

NOTE 1 : The location of the selection process in a separate entity is out of scope for this release. 

NOTE 2: Admission control procedures for use of transport resources at the CoD-MF side are out of scope for this 
release. 

The CoD-SCF shall contact the CoD-MCF during the session initiation and resource allocation phase. The CoD-SCF 
may contact several CoD-MCFs before its determination. The CoD-SCF contacts the CoD-MCF via the Core IMS as 
shown in figure 4. 
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ISC 




y2 




Figure 4: Reference points between CoD-SCF and CoD-IVICF 

When the CoD-MCF is contacted, it shall respond with the parameters offer for the CoD session corresponding to the 
content required by the UE. 

The CoD-MCF controls one or several CoD-MDFs. Tasks of the CoD-MCF are the following: 

• Select a CoD-MDF. 

• Control the media stream resources in the CoD-MDFs. 

• Interpret information coming from the CoD-SCF and control the CoD-MDFs accordingly. 

• Generate of CDRs. 

Selection of the CoD-MDF by the CoD-MCF uses similar criteria to the selection of a CoD-MCF by a CoD-SCF. And 
in some cases, the selection task of CoD-MCF may become very simple. For e.g., if a Request-URI for service/content 
identifier corresponds to just one MDF, then MCF may just transfer the session to the unique MDF. 

5.3 Interactions between BC Service Control Functions and BC 
Media Functions 

There are no direct interactions between the BC Service Control Functions and the BC Media Functions. However both 
types of functions shall be provisioned with consistent network parameters for each of the content channels. 



6 Reference points 

6.1 UE-SSF(Xa) 

This reference point between UE and SSF is used by the UE to make appropriate service selections. 

6.2 UE - IPTV Service Control Functions (Ut) 

This reference point between UE and IPTV Service Control Functions is used by the UE for the purpose of service 
profile configuration. 

Use of the Ut reference point conforms to ES 282 007 [11]. 
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6.3 UE - Core IMS (Gm) 

Use of the Gm reference point conforms to ES 282 007 [11]. 

6.4 UE - Media Control Functions (Xc) 

This Xc reference point (for media control) is a logical end-to-end reference point between the UE and the IPTV Media 
Control Function that is used to exchange media control messages for controlling the IPTV Media flow. 

NOTE: transport related reference points are used to carry media control messages over underlying transport 

segment (defined in ES 282 001 [1] and as shown in figure 5 depending on the location of the MCE. The 
Dj reference point between the UE and the access network, the Di reference point between the access 
network and the core network, and possibly the Ds or Iz reference point between the core network and the 
Media Control Function if the MCF is located after the Core Network. 



r \ 



UE 




Core Network Transport Processing 



Ds or Iz 



V 



MCF 



Xc 



Figure 5: Decomposition of thie Xc reference point when the IVICF is after the core networic 

6.5 UE - Media Delivery Functions (Xd) 

This Xd reference point (for media delivery) is a logical end-to-end reference point between the UE and the IPTV 
Media Delivery Function that is used to deliver media data. 

NOTE: transport related reference points are used to carry media delivery data over underlying transport segment 
(defined in ES 282 001 [1] and as shown in figure 6 depending on the location of the MDF. The Dj 
reference point between the UE and the access network, the Di reference point between the access 
network and the core network, and possibly the Ds or Iz reference point between the core network and the 
Media Delivery Function if the MDF is located after the Core Network. 




Figure 6: Decomposition of the Xd reference point 

If the IPTV system architecture supports QoS and/or QoE [7] and [i.l], this reference point may carry QoS and/or QoE 
reports from the UE to the MDF. These reports relate to the quality of the IPTV Media Data that the UE receives. 

6.6 IPTV Service Control Functions (SCF) - UPSF (Sh) 

Use of the Sh reference point conforms to ES 282 007 [11]. 
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6.7 Core IMS - UPSF (Cx) 

Use of the Cx reference point conforms to ES 282 007 [11]. 

6.8 Core IMS - IPTV Service Control Functions (ISC) 

Use of the ISC reference point conforms to ES 282 007 [11]. 

6.9 Core IMS - IPTV Media Functions (y2) 

This reference point between S-CSCF and IPTV Media Control Function (MCE) carries IPTV Service Control 
Signalling originating from the IPTV Service Control Function (SCE) to control the MCE. 

In case the CSCE and the Media Control Function are in different administrative domains, signalling flows go through 
an IBCF. 

NOTE: As stated in TS 123 228 [12] (referred to by TS 182 006 [2]), an AppUcation Server may originate 

requests to a destination without involving the S-CSCE. This capability should be used in case the SCE is 
to communicate with the media function without involving the core-IMS, thus omitting y2. 

6.10 Core IMS - SDF (ISC) 

Use of the ISC reference point conforms to ES 282 007 [11]. 

6.11 SDF- UPSF (Sh) 

Use of the Sh reference point conforms to ES 282 007 [11]. 

6.12 Void 

Void. 

6.13 Application Functions - MASS (e2) 

Use of the e2 reference point conforms to ES 282 007 [11] and ES 282 004 [3]. 

NOTE: Application Function entities associated to IPTV services such as core IMS and SCE may query the UE 
location from the CLE in order to fulfil their tasks. 

6.14 Core IMS - RACS (Gq') 

Use of the Gq' reference point conforms to ES 282 007 [1 1] and ES 282 003 [8]. 

6.15 MASS - RACS (e4) 

Use of the e4 reference point conforms to ES 282 003 [8] and ES 282 004 [3]. 

6.16 IPTV Service Control Functions - SLF (Dh) 

Use of the Dh reference point conforms to ES 282 007 [11]. 
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6.17 Core IMS - SLF (Dx) 

Use of the Dx reference point conforms to ES 282 007 [11]. 

6.18 IPTV Media Control Function - IPTV Media Delivery 
Function (Xp) 

This Xp reference point between the Media Control Function (MCF) and Media Delivery Function is used to control 
media delivery sessions to support media delivery session setup when content is distributed across one and more media 
delivery functions. 



7 User data 

7.1 Classification of information 

Four categories of user data are involved in providing IPTV services: 

• IMS-profile: This category includes all information required to establish IMS sessions and access IPTV 
services hosted in Application Servers, as described in TR 182 005 [i.3]. 

• Communication Services profile: This category encompasses all information associated to communication 
services (e.g. PSTN/ISDN simulation services, presence services, messaging services, etc.) as defined in 
relevant ETSI TISPAN standards (e.g. TS 183 004 [9]). This type of information is required in support of 
combinational services (e.g. Caller Id on TV Screen). 

• IPTV user profile: This category encompasses all information required to operate an IPTV service. This 
includes all the user settings regarding: 

Global settings (Language preference, etc.). 

Broadcast settings. 

List of subscribed BC service packages. A BC service package is a set of elementary BC TV services, 
along with a description. These BC services have the same authorization and charging policy. A BC 
IPTV service is for instance a multicast channel, interactive channel, mosaic that a user may subscribe to. 

NOTE 1 : The Broadcast settings only provide a reference to service package and/or associated services that a given 
IPTV user has subscribed to and is not meant to be a complete description of the service package and/or 
service. The complete service package and/or service description is available in an associated IPTV 
Service Profile definition (e.g. described with metadata). If the list of elementary IPTV services 
associated with a given service package are not explicitly listed in the IPTV user profile, then it implies 
that the IPTV user has implicitly subscribed to all of the IPTV services within that service package. 

Content on demand settings (Parental control level, etc.). 

PVR settings (PVR preferences network/local, PVR user restrictions, PVR storage limit). 

UE Settings which includes information related to the capabilities of the UE(s) that an IPTV user is 
associated with. An IPTV user may be associated with one or more UE(s) and every UE is uniquely 
identified with a unique UE Identifier (UE ID). The UE capabilities associated with an IPTV user profile 
may be used for customization of IPTV service selection data that is provided by the SSF to the IPTV 
user (based on capabilities of the UE that the IPTV user is currently associated with). For instance, an 
IPTV user on a SD-only device would not be provided with information related to HD services. 

The UE settings is not intended to cover all information related to the UE and currently holds only the 
UE capabilities attribute since this information may be used by the SSF for personalized service 
selection. Note that detailed information about the UE may be located elsewhere and can be referenced 
by the IPTV user profile using the UE ID parameter. 
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Further details are provided in clause 7.3. 



• IPTV service action data: This category encompasses information related to the actions the user may have 
taken while accessing services such as BC or CoD (e.g. ordering a CoD - Choosing to pause while viewing a 
live event). Those data are required to enable IPTV session portability for the user. 

They include: 

■ The list of CoDs that the user has ordered and associated status, CodOffset which is offset in the 
content where the user has paused and CodOffsetExpiryTime which is expiration time associated 
with the CodOffset value. 

■ The list of BC TV services (or programmes) that the user has paused (and is hence likely to resume 
later) including the bookmark value associated with the paused BC TV service or Programme and 
BookMarkExpiryTime which is expiration time associated with the bookmark value. 

■ The list of N-P VR contents that the user has asked to be recorded. This would include the 
following parameters: 

o N-PVRContentId: it refers to a content identifier used by the UE to activate an N-PVR session 
related to the N-PVR content. 

NOTE 2: In the case when a specific programme has been requested to be recorded, this ID would be the same as 
ProgrammelD, and the RecordStartDate and RecordEndDate attributes would be optional. 

BCServiceld: the identifier of the BC service that is to be recorded. 

(Optionally)] RecordStartDate: the start date (and time) of the recording. 

(Optionally) RecordEndDate: the end date (and time) of the recording. 

(Optionally) RecordDescription: a description of the recording made by the user when he/she 
requested to record the live content. 

RecordStatus: the status of such a recording (requested - scheduled - available - failed). 

RecordOffset: the offset in the N-PVR content where the user might have paused while actually 
watching it. 

RecordOffsetExpiryTime: expiration time associated with the RecordOffset. 

RecordExpiryTime: the expiration time associated with the recording value. 

A Boolean flag, user action recordable, may be associated with IPTV user profile information to indicate 
if the user wishes to have the service persist such data or not. Further details are provided in 
clause 7.3.1.6. 

The relationships between the IMS profile and the dedicated IPTV user data categories are as follows: 

■ IPTV user profile: This profile is associated with an IMS Public User Identity (IMPU). This would 
enable for instance enforcement of parental control on a per-user basis independent of the device 
they are using. 

■ IPTV service action data: This profile is associated with an IMS Public User Identity (IMPU). This 
would enable for instance "follow me TV/video" kind of scenarios wherein users can resume the 
viewing of content on any device that they are authorized to use. 
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7.2 Location and access to user data 

7.2.1 Data management functions 

IMS-profile information is managed by the UPSF. Communication Services profile information may be managed by 
dedicated database functions, the Application Server functions hosting the communication services, or by the UPSF as 
transparent data (repository function) associated to these Application Server functions. In the first and second case the 
Application Server function or the stand-alone server may exhibit the behaviour of an XDMS. 

IPTV user profile information should be located in the following locations: 

• Application Server functions hosting the IPTV applications. 

• In a stand-alone server associated with one or more Application Server functions. 

• In the UPSF as transparent data associated to these Application Server functions. 

The first and second options are recommended for data to be accessed by 3rd party application server functions. In the 
first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an XDMS. 

IPTV service action data needs to be persistent across IPTV sessions, and should be located in the network. They may 
be located in one of the following locations: 

• The Application Server functions hosting the IPTV applications. 

• A stand-alone server associated with one or more Application Server functions. 

• In the UPSF as transparent data associated to these Application Server functions. 

In the first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an 
XDMS. 

7.2.2 Access from otiner application servers 

User data stored in the UPSF can be accessed by Application Servers at the Sh reference point. 

Direct access to user data stored in Application Servers is outside the scope of the present document. However, part of 
these data may be indirectly exposed through Web Services and/or SIP Event packages. 

7.2.3 Access from User Equipment (UE) 

A subset of IPTV user-profile information may be accessed from the User Equipment at the Ut reference point. 

7.2.4 Access from tine SSF 

For the purpose of personalized service selection, the SSF may need to access user data. 

In the case when such user data is stored in the UPSF, it can be accessed by the SSF at the Sh reference point when the 
SSF is in the same domain. 

On the contrary, when such user data is stored in the AS or in a stand alone server associated with one or more 
application servers or if the SSF in not in the same domain as the UPSF, the user data can be accessed by the SSF using 
an reference point that is out of scope for this release. 

The SSF may also request notification of IPTV user data updates. 
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7.3 IPTV user profile structure 



7.3.1 IPTV user profile structure 

An IPTV user profile comprises: 

• zero, one or more instances of the UE object class comprising UE capabilities attribute and associated UE ID; 

• at least one instance of a Broadcast (BC) or a Content on Demand (CoD) object class (see figure 7); 

• zero or one instance of the Global settings object class; 

• zero or one instance of the Network Personal Video Recorder (N-PVR) object class. 
A Broadcast profile comprises one or more BC Service package descriptions. 

Each BC service package comprises zero or more BC TV Services descriptions. 

Each BC TV service includes a quality definition level (e.g. standard or high definition or other defined quality level). 
Delivered quality level depends on this quality definition level as well as UE capabilities, available codecs and/or 
bandwidth limitations. 

NOTE: When there is no service description for a given BC service package, it would imply that the IPTV user 
has access to all of the BC services within that given BC service package. 

The complete service package and/or service description is available in an associated IPTV Service Profile definition 
(e.g. described with metadata). The ServicePackageld attribute associated with the service package and/or the Serviceld 
attribute associated with the service refers to appropriate descriptions in an associated IPTV Service Profile definition 
(e.g. described with metadata) and hence, can be used to fetch detailed information about the particular service package 
and associated services. 

A CoD profile includes a parental control level (ParentalControlLevel) attribute. 

An N-PVR profile contains N-PVR rules for the user. 
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Figure 7: IPTV user profile data model 
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This data model assumes that each IPTV user is allocated at least an IMS Public User Identity and an IPTV user profile 
is associated with this IMS Public User Identity. 

Multiple IPTV users may share the same IMS subscription. 

The IPTV user identity (i.e. the IMS Public User Identity) selected when making an outgoing request is asserted by the 
UE using means outside the scope of the present document (e.g. using a local pin code). 

7.3.1 .1 BC service package 

A service package is a group of one or more BC service. 

7.3.1.2 BC service 

A service relates to a particular TV channel and associated quality definition (e.g. SD or HD). 

7.3.1.3 UE 

Contains the UE's Id and its capabilities. 

7.3.1 .4 Global settings: language preference 

This attribute defines which default language the user would like to use. For instance, this could be the default language 
for the GUI that is displayed on the UE, and/or the default language used for subtitles. 

7.3.1 .5 Global settings: user action recordable 

The "user actions recordable" parameter indicates whether user actions can be recorded by the network as part of the 
IPTV service action data. 

7.3.1.6 N-PVR storage-limit 

This attribute defines a limit allocated per user for N-PVR contents. 

It can be expressed in time or volume. 

There can be several occurrences of this parameter. 

7.3.2 Usage of IPTV user profile 

The IPTV user profile may be used to customize the user IPTV experience. 
For instance: 

• The CoD profile parental control Level should be used to filter a CoD catalogue. 

• The UE capabilities associated with an IPTV user profile UE data may be used for customization of IPTV 
service selection data that is provided by the SSF to the IPTV user (based on capabilities of the UE that the 
IPTV user is currently associated with). 

Thanks to the IPTV user profile standardization, any equipment can render the same IPTV environment to the user. The 
IPTV user profile may also be used to allow or deny access to IPTV services. 

7.3.3 Life cycle 

UE List: The information about the UE(s) that an IPTV user is currently associated with may be purged when the IPTV 
user deregisters and/or logs off. This is to avoid persisting UE related information when the IPTV user logs off that 
particular UE. 
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7.4 



IPTV service action data 



7.4.1 



Data model 
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CoDOffset: string 
CoDOffsetExpiryTime: timestamp 



Figure 8: IPTV Service action data - data model 

This data model assumes that each IPTV user is allocated at least an IMS Public User Identity and an IPTV Service 
Action data profile is associated with this IMS Public User Identity. 

NOTE 1 : The "Programmeld" attribute is unique, as it refers to one and only one entry in the EPG. 

NOTE 2: Although the "Bookmark" attribute could be used as an indirect way to identify the programme, it is seen 
as more convenient and immediate to use the Programmeld for that purpose. 

7.4.2 Life cycle 

• CoD list: Items may be removed when they are no longer accessible (e.g. the offer they were attached to has 
expired.) or when the entitled number of visualizations has been reached. Alternatively, items are purged when 
the expiration time associated with the CoDOffset (identified using CoDOffserExpiryTime) expires. 

• BC bookmarks are kept in the profile while the BC TV service or Programme they refer to is available in the 
media server. Alternatively, entries may also be purged when the expiration time associated with BookMark 
value (identified using BookmarkExpiryTime) expires. 

• N-PVR items are kept in the profile while the content they refer to is available in the Network PVR server(s). 
Alternatively, entries may also be purged when the expiration time associated with Recording value (identified 
using RecordExpiryTime) expires. Failed recordings may be purged on a regular configurable basis. 
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8 



Procedures 



8.1 I PTV addressing mechanisms 

8.1 .1 IPTV end-users identification and addressing mecinanisms 

End-user identification and addressing shall be done according to what is defined in document TS 182 006 [2]. 

8.1 .2 Addressing of nodes 

As specified by TS 182 006 [2], those network nodes with reference points supporting the SIP protocol shall be 
identifiable using a valid SIP URL 

8.2 UE start-up procedure 

Figure 9 depicts the typical steps that occur at power up of the UE. Some of the steps are not new in themselves, but 
exist already in NGN. 



UE 



NASS 



Core IMS 



\^) Network Attachment 



(2) IMS Registration 



(3) Attach to the IPTV Service 



SDF 



SSF 



(4) Selection of IPTV Service 



Figure 9: UE start-up procedure 

(1) Network Attachment 

In this step the UE attaches to the network. The procedures for network attachment are defined in 
ES 282 004 [3]. This step includes IP configuration, P-CSCF address discovery, etc. 

(2) IMS Registration 

In this step, the UE performs regular IMS Registration as defined in TS 182 006 [2]. 
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(3) Service Attachment 

In this step, the UE retrieves the configuration information (server addresses and other relevant information) 
needed to retrieve the appropriate information to access the services that the user is authorized to. The user 
preferences and the capabiHties of the UE can be taken into account to enable personalized service discovery. 
The UE could retrieve the service discovery information through the Push mode and Pull mode. 
Push mode: When the UE attaches to the IMS network, the SDF actively sends the service attachment 
information to the UE. 

Pull mode: After the UE attaches to the IMS network, the UE actively requests the service attachment 
information from the SDF. 

NOTE 1: The SDF discovery can be performed in several ways: through NASS attachment, by manual provisioning, 
using IFC e.g. third-party registration, etc. 

(4) Service Selection 

In this step, the UE retrieves data related to specific services and makes appropriate service selection. 

NOTE 2: In case the UE needs to directly contact a network functional element, (e.g. a Service Control 

Function - SCF, or SSF), it should perform GB A authentication, for key management purposes. This 
procedure will secure further communication taking place between the UE and the IPTV Service Control 
Function. The GBA bootstrapping procedure is defined in GAA - TS 133 220 [4] and is referenced in the 
TISPAN NGN Security architecture - TS 187 003 [5]. This step is not affecting the functional behaviour of 
any of the entities involved in this start-up phase and thus, it is not displayed in this flow. 

The detailed sequence of steps 3-4 is described in figure 10. 
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Figure 10: IPTV service attachment and selection in pull mode 

(1) The UE makes a service attachment request. 

(2) The core IMS relays the request to the appropriate entity (here, SDF). 

(3) The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the 
location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any 
other entity where it is stored. 

(4) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

(5) Core IMS relays the configuration information related to IPTV services back to UE. 

(6) The UE requests the SSF to get the selection data. 

(7) The SSF delivers the requested data to the UE. 
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For the purpose of service configuration update, steps 4 and 5 described above can be repeated at any time after 
completion of the IPTV service attachment and selection procedure. 



UE 



Core IMS 



(4) Service Config Info(EIected 
SSF address,...) 



(5) request selection data 



SDF 



User Profile 



(1) Getting the status of the UE 



SSF 



I (2) SSF Election 

I 

(3) Service Config Info i 

Elected SSF address....") 



(6) retrieve sel 



action data (EPG, CoD cata 



og, ...) 



Figure 1 1 : IPTV service attachment and selection in push mode 

(1) The SDF gets the status of the UE, e.g. the S-CSCF sends a third-party REGISTER request to the SDF after 
the IMS Registration or by other method, then the SDF gets the status of the UE. 

(2) The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the 
location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any 
other entity where it is stored. 

(3) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

(4) Core IMS relays the configuration information related to IPTV services back to UE. 

(5) The UE requests the SSF to get the selection data. 

(6) The SSF delivers the requested data to the UE. 



8.3 



Broadcast session 



Before the User Equipment can join a multicast channel, a session initiation procedure shall take place as described in 
clause 8.3.1. One session initiation is associated to one or more service packages. SCF does not participate in channel 
change control in order to avoid zapping delays. 

The UE retrieves necessary network parameters to handle the BC TV Service either before the session initiation 
procedure (from the SSF) or as part of the session initiation procedure (from the SCF). 

The SSF and/or the SCF acquire network parameters from management entities. 

NOTE: Alternative methods could exist, but they out of scope for this release. 
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The session may be modified using the procedure described in clause 8.3.2 in the following cases: 

• The BC TV Service is modified. 

• Currently allocated resources are not sufficient and the User Equipment wishes to join a multicast channel with 
different QoS requirements (e.g. zapping from a SD to HD channel). The session modification procedure may 
take place before or after the request to change channel, in order to avoid increasing zapping delays. In the 
later case, the session modification procedure is initiated by the UE and the new channel is delivered using 
currently allocated resources until this procedure and any additional resource reservations that may be required 
are completed. 

The session can be terminated by the User Equipment using the procedures described in clause 8.3.3 or by the network. 

Interactions between the IMS and the RACS take place at different steps of the session initiation and modification and 
release. Additional resource control procedures not triggered by the IMS may also take place and are not described in 
the following clauses. 

8.3.1 Signalling flows for broadcast session initiation 
8.3.1 .1 Overview of the signalling flows for session initiation 

Figure 12 provides an overview of the information flows for initialization of the BC session. 
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Figure 12: Broadcast session initiation 

(1) The UE initiates a dialogue to the BC service which refers to the service package(s). 

(2) The session initiation request is routed by the Core IMS entities up to the SCF in charge of the requested BC 
service. 

(3) Signalling procedures for the establishment of one or more content delivery channels network parameters 
necessary to handle the BC service take place between the UE and the SCF (see clause 8.3.1.2). 

NOTE: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session initiation. 

(4) The SCF confirms the dialogue establishment. 
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(5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources and to activate the service 
package(s) in transport network element at edge of network for enabling multicast joining. 

(6) The P-CSCF forwards the dialogue confirmation to the UE. 

(7) The UE starts joining multicast channels and receiving multicast flows. 

8.3.1 .2 Signalling flows for the establishment of the delivery channel 

Figure 13 shows information flows applicable when SCF initiates the establishment of content delivery channel. 
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Figure 13: Establishment of the delivery channel 

(42) The SCF initiates the establishment of one or more content delivery channels with the UE, by sending a media 
offer through the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS according to the description given in the media 
offer. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 

(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the configuration according to the media 
answer. 

(47)The media answer is propagated to the SCF. 

Figure 14 provides an overview of the information flows for UE-initiated establishment of content delivery channel 
necessary to handle the BC service. 
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Figure 14: Establishment of the delivery channel 

(41) The UE initiates the estabHshment of one or more content deHvery channels with the SCF, by sending a media 
offer through the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources according to the media 
offer. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF sends a media answer through the Core IMS. 

(45) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(46) The media answer is propagated to the UE. 

8.3.2 Signalling flows for BC session modification 

The BC session modification procedure is used to modify network parameters necessary to handle the BC service in an 
existing session. 

The BC session modification procedure is initiated by the UE or the SCF. 

Figure 15 provides an overview of the information flows for UE-initiated BC session modification. 
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Figure 15: UE-initiated BC session modification 

(1) The UE initiates a session modification procedure in order to start a modification of network parameters 
necessary to handle the BC service. 

(2) The session modification request is forwarded to the SCF through the Core IMS. 

(3) Procedures for the negotiation of the network parameters necessary to handle the BC service take place 
between the UE and the SCF (see clause 8.3.1.2). 

NOTE 1: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session modification. 

(4) The SCF acknowledges the session modification. 

(5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. 

(6) The P-CSCF forwards the confirmation to the UE. 

(7) The UE starts joining multicast channels and receiving multicast flows. 

Figure 16 provides an overview of the information flows for SCF-initiated session modification. 
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Figure 16: SCF-initiated BC session modification 

(1) The SCF initiates a session modification procedure in order to start a negotiation for network parameters 
necessary to handle the BC service. 

(2) The session modification request is forwarded to the UE by the Core IMS. 

(3) Procedures for the negotiation of the network parameters necessary to handle the BC service take place 
between the UE and the MP (see clause 8.3.1.2). 

NOTE 2: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session modification. 

(4) The UE confirms the modification of the session. 

(5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. 

(6) The Core IMS forwards this modification to the SCF. 

(7) The UE starts joining multicast channels and receiving multicast flows. 



8.3.3 Signalling flows for broadcast session release 

Figure 17 provides an overview of the information flows for UE-initiated session release. 
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Figure 17: UE-initiated broadcast session release 

(1) The UE initiates a session termination. 

(2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session 
and to deactivate the service package in transport network element to prevent invalid multicast joining. 

(3) The Session Termination Request is routed by the Core IMS entities up to the SCF. 

(4) The SCF returns a Session Termination Confirm to the Core IMS. 

(5) The P-CSCF forwards the Session Termination Confirm to the UE. 

Figure 18 provides an overview of the information flows for SCF-initiated session release. 
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Figure 18: SCF-initiated broadcast session release 
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(1) The SCF initiates a session termination. 

(2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session 
and to deactivate the service package in transport network element to prevent invalid multicast joining. 

(3) The Session Termination Request is routed by the Core IMS entities up to the UE. 

(4) The UE returns a Session Termination Confirm to the Core IMS. 

(5) The Core IMS forwards the Session Termination Confirm to the SCF. 

8.3.4 Signalling flow for Broadcast TV channel switching 

Figure 19 provides an example of a signalling flow for channel switching. It shows how the SCF can be informed about 
what channel is currently being watched. 
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Figure 19: Broadcast TV channel switching 

(1) The UE leaves a multicast channel and joins another multicast channel. 

(2) A delay may be applied. If the user switches channel again during this delay time, the flow is restarted at 
step 1. 

(3) The UE sends information about which channel is being watched. 

(4) Core IMS routes the information to the SCF. 

8.3.5 Signalling flows for transition from Broadcast TV to Broadcast TV 
with trick play 

Figure 20 provides the signalling flow for trick play of a Broadcast TV channel. In order to apply trick modes to a 
Broadcast TV session, this must be established as indicated in clause 8.3.1. 

The same session is used in the trick play session modification, in order not to change the bandwidth requirements on 
the network. At successful conclusion of these procedures the UE seamlessly transitions from viewing Broadcast TV to 
Broadcast TV with trick play. 

NOTE 1 : As an alternative to the session modification, it is possible to initiate a separate session for trick modes 
handling, in addition to the Broadcast TV one, while keeping control of the bandwidth requirements 
between the two of them. This method is, however, out of the scope of the present document. 
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Figure 20: Signalling flow for initiating trick play of broadcast TV channel 

(1) Broadcast TV session initiation. 

NOTE 2: The procedures are the same as clause 8.3.2, Overview of the signalling flows for session initiation. 
RACS and channel establishment have been removed for purpose of simplification. 

(2) The UE sends information on the current channel being watched, in order for the SCF to know what channel 
should be recorded. 

(3) Core IMS routes the information to the SCF. 

(4) When the UE initiates trick play mode of a Broadcast TV the UE sends a session modify request which 
includes a media offer for a content control channel and content delivery channel with the MF. If trick play 
service is not available for the UE, the session modification is not sent. 
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NOTE 3: The Broadcast TV with trick play session modification is performed on the same session as the Broadcast 
TV session initiation. The existing reservation (for broadcast) needs to be modified to add a unicast flow 
that reuses the resources dedicated to the user. In the figure, RACS has been combined with Core IMS for 
the purpose of simplification. 

NOTE 4: Steps 2 and 3 are optional in a generic Broadcast TV session, but are required if trick play is activated. 
The implementation of both steps as separate messages or combined with step 4 is an implementation 
issue. 

(5) After reserving resources in RACS Core IMS forwards the session modification request to the SCF. 

(6) The SCF forwards the session modification request as a new session initiation to the MP along with the 
channel indication. The MF will determine if the programme currently broadcasted has trick play support. 
Prior to replying the MP uses real time to calculate the media offset for the broadcast TV channel when 
replying with the offered media. If trick play service is not available for the UE the session modification is 
rejected and the old Broadcast TV session initiation (along with the previous reserved committed resources) is 
maintained. 

(7) The MF sends the session modification response to the SCF. 

(8) The SCF forwards the session modification response to the Core IMS. 

(9) After committing resources in RACS Core IMS forwards the session modification response to the UE. 

(10) The UE leaves the multicast channel. 

(11) The UE starts playing content and receiving unicast flow. 
NOTE 5: Alternatives to the above call-flow are for further study. 

8.3.6 Signalling flows for transition from Broadcast TV with trick play to 
Broadcast TV 

The UE returns from Broadcast TV trick play to linear Broadcast TV, for example when the UE switches channels from 
a paused channel to another live Broadcast TV channels, or when the UE fast-forwarding in a unicast stream and 
catches up with the live Broadcast TV channel. 

The trigger to transition from Broadcast TV with Trick Play to Broadcast TV may be initiated by the UE, SCF or MCF. 

NOTE: The event to trigger the transition is outside of the present document. 

The UE or SCF may request a Broadcast TV session modification as described in clause 8.3.2. The difference is that the 
Broadcast TV session modification is performed on the same session, in order to release unicast resources, and the SCF 
is responsible for releasing the resources in the MCF with a session termination request/response. 

The MCF may request a session termination towards SCF which in turn performs Broadcast TV session modification 
towards the UE. 

8.3.7 Signalling flows for Broadcast TV with trick play session release 

When the UE terminates the Broadcast TV with trick play the UE shall follow the same flows as clause 8.4.3. 

8.4 CoD session 

8.4.1 Signalling Flows for CoD session initiation 

Before the User Equipment can view the content, a session initiation procedure shall take place as described in 
clause 8.4.1. 

The UE retrieves necessary network parameters to handle the CoD service before the session initiation procedure (from 
the SSF), or as part of the session initiation procedure, or after the session initiation procedure (from the MP). 
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The session can be terminated by the User Equipment using the procedures described in clause 8.4.3 or by the network. 

Interactions between the IMS and the RACS take place at different steps of the session initiation/modification and 
release. 

In certain cases such as in conventional content server deployments, it may be preferable that a content control channel 
and content delivery channel(s) be established separately. 

8.4.1 .1 Overall signalling flows 

Figure 21 provides an overview of the information flows for initialization of the CoD session. 
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Figure 21 

(1) The UE initiates a dialogue to the CoD service. 

(2) The session initiation request is routed by the Core IMS entities up to the SCF in charge of the requested CoD 

service. 

(3) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to access the content, 
the SCF forwards the session initiation request to the selected MF. 

(4) Signalling procedures for establishment of a content control channel and optionally (Note 2) content delivery 
channels take place between the UE and the MF (see clause 8.4.1.2). 

NOTE 1: In a particular protocol realization, the messages supporting step 4 may be embedded in the messages 
supporting session initiation. 

NOTE 2: The establishment of the content delivery channel in the session initiation is only optional when network 
has provided information for only content control channel setup. In this case, the content delivery channel 
is established during session modification. 
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(5) The MF confirms the estabhshment of the dialogue with the UE. 

(6) The SCF forwards this confirmation to the Core IMS. 

(7) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for exchanging content control messages and/or content delivery. 

(8) The P-CSCF forwards the dialogue confirmation to the UE. 

After this point, UE may use the content control channel to request content to be streamed and the actual content will be 
then delivered/streamed over the content delivery channels. 

The content control channel will also be used to carry UE requests for controlling the streams, e.g. "pause", "fast 
forward", etc. 



8.4.1.2 



Media Channel Negotiation 



The following clauses go into details related to step 4 in the session initiation in clause 8.4.1.1. 

8.4.1 .2.1 Signalling flows for the establishment of the content control and content delivery 

channels from MF 

Figure 22 shows information flows applicable when network parameters necessary to handle the CoD service are 
provided by the MF as part of the session initiation procedure. This set of information flows assume that the UE does 
not receive a description of the network parameters required from the SSF before initiating the session. 
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Figure 22 

(41) The MF initiates negotiation of a content control channel and one or more content delivery channels with the 
UE, by sending a media offer to the SCF. 

(42) The media offer is forwarded to the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content 
control channel and one or more content delivery channels. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 
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(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the reservation (optional). 

(47) The media answer for the content control channel and one or more content delivery channels is propagated to 
the SCF. 

(48) The SCF forwards the media answer to the MF. 

8.4.1 .2.2 Signalling flows for the establishment of the content control and content delivery 

channels from UE 

Figure 23 provides an overview of the information flows for UE-initiated negotiation of the network parameters 
necessary to handle the CoD service. This set of information flows assume that the UE receives a description of the 
network parameters required from the SSF before initiating the session. 
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Figure 23 

(41) The UE initiates negotiation of a content control channel and one or more content delivery channels with the 
MF, by sending a media offer to the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content 
control channel and one or more content delivery channels. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF forwards the media offer to the MF. 

(45) The MF provides a media answer to the SCF. 

(46) The SCF forward the media answer to the Core IMS. 

(47) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(48) The media answer for the content control channel and one or more content delivery channels is propagated to 
the UE. 
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8.4.1 .2.3 Signalling flows for the establishment of the content control channel from UE 

Figure 24 provides an overview of the information flows for UE-initiated establishment of the content control channel. 
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Figure 24 

The UE initiates negotiation of a content control channel with the MF, by sending a media offer to the Core 
IMS. 

The P-CSCF within the Core IMS interacts with the RACS to reserve transport resotirces for the content 
control channel. 

The media offer is forwarded to the SCF. 

The SCF forwards the media offer to the MF. 

The MF provides a media answer to the SCF. 

The SCF forward the media answer to the Core IMS. 

Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

The media answer for the content control channel is propagated to the UE. 



8.4.2 Signalling Flows for CoD session modification 

The CoD session modification procedure is used to add, remove or modify one or more content delivery channels in an 

existing session. 

The CoD session modification procedure is initiated by the UE or the MF. 

The session modification procedure shall take place immediately after the session initiation procedure (e.g. using 
network parameters retrieved from content control messages) when no content delivery channels were set during this 
previous phase. 

In case of a session modification, the content delivery channel setup/modification procedure is always triggered by the 
entity initiating the session modification. 

Figure 25 provides an overview of the information flows for UE-initiated CoD session modification. 
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Figure 25 

(1) The UE initiates a session modification procedure in order to start a negotiation for one or more content 
delivery channel(s). 

(2) The session modification request is forwarded to the SCF through the Core IMS. 

(3) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to modify the content, 
the SCF forwards the session modification request to the MF. 

(4) Procedures for establishment of a content delivery channels take place between the UE and the MF 
(see clause 8.4.2.1). 

NOTE: The messages supporting step 4 are embedded in the messages supporting session modification. 

(5) The MF confirms the modification of the session. 

(6) The SCF forwards this modification to the Core IMS. 

(7) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for content delivery. 

(8)The P-CSCF forwards the confirmation to the UE. 

After this point, UE may request content to be delivered over the content control channel and the actual content will be 
then delivered over the content delivery channels. 

The content control channel will also be used to carry UE requests for controlling the streams over the content delivery 
channels, e.g. "pause", "fast forward", etc. 

Figure 26 provides an overview of the information flows for MF-initiated CoD session modification. 
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Figure 26 

(1) The MF initiates a session modification procedure in order to start a negotiation for one or more content 
delivery channel(s). 

(2) The SCF performs service authorization as described in clause 5.1. The SCF forwards the session modification 
request to the MF. 

(3) The session modification request is forwarded to the UE by the Core IMS. 

(4) Procedures for establishment of a content delivery channels take place between the UE and the MF 
(see clause 8.4.2.2). 

NOTE: The messages supporting step 4 are embedded in the messages supporting session modification. 

(5) The UE confirms the modification of the session. 

(6) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for content delivery. 

(7) The Core IMS forwards this modification to the SCF. 

(8) The SCF forwards the confirmation to the MF. 

After this point, UE may send a request over the content control channel to stream content and the actual content will be 
then delivered over the content delivery channels. 

The content control channel will also be used to carry UE requests for controlling the content streams e.g. "pause", "fast 
forward", etc. 
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8.4.2.1 Signalling flows for the establishment/modification of the content delivery 

channel from UE 

Figure 27 provides an overview of the information flows for UE-initiated establishment or modification of the content 
delivery channel. 
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Figure 27 

(41) The UE initiates negotiation of one or more content delivery channel with the MF, by sending a media offer to 
the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content 
delivery channels. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF forwards the media offer to the MF. 

(45) The MF provides a media answer to the SCF. 

(46) The SCF forward the media answer to the Core IMS. 

(47) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(48) The media answer for the content delivery channels is propagated to the UE. 

8.4.2.2 Signalling flows for the modification of the content delivery channels from MF 

Figure 28 provides an overview of the information flows for MF-initiated modification of the content delivery channel. 
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Figure 28 

(41) The MF initiates negotiation of one or more content delivery channels with the UE, by sending a media offer 
to the SCF. 

(42) The media offer is forwarded to the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content 
delivery channels. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 

(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the reservation (optional). 

(47) The media answer for the content delivery channels is propagated to the SCF. 

(48) The SCF forwards the media answer to the MF. 



8.4.3 Signalling Flows for CoD session release 

Figure 29 provides an overview of the information flows for UE-initiated session release. 
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Figure 29 

(1) The UE initiate a session termination. 

(2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

(3) The Session Termination Request is routed by the Core IMS entities up to the SCF. 

(4) The SCF forwards the Session Termination Request to the appropriate Media Function. 

(5) The Media Function (i.e. the MCF) release all resources associated with the session and returns a Session 
Termination Confirm. 

(6) The SCF forwards the Session Termination Confirm to the Core IMS. 

(7) The P-CSCF forwards the Session Termination Confirm to the UE. 

Figure 30 provides an overview of the information flows for SCF-initiated session release. 



UE 



RACS 



Core IMS 



SCF 



MF 



(3) Session Termina|tion 
Request 



(4) Resources release 



(5) Session Term nation Request 



(6) Session Termir ation Confirm 



(7) Session Termina|tion 
Confirm ». 



(1) Session Term inat 
Request ^ 



(2)Session Term inatipn 
Confirm 



on 



Figure 30 
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(1) The SCF initiates a session termination towards the MF. 

(2) The Media Function (i.e. the MCF) releases all resources associated with the session and returns a Session 
Termination Confirm. 

(3) The SCF initiates a session termination towards the UE. 

(4) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

(5) The Session Termination Request is routed by the Core IMS entities up to the UE. 

(6) The UE returns a Session Termination Confirm to the Core IMS. 

(7) The Core IMS forwards the Session Termination Confirm to the SCF. 

Figure 3 1 provides an overview of the information flows for MF-initiated session release. 
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Figure 31 

(1) The MF initiates a session termination towards the SCF. 

(2) The SCF forwards the session termination request to the Core IMS. 

(3) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

(4) The Session Termination Request is routed by the Core IMS entities up to the UE. 

(5) The UE returns a Session Termination Confirm to the Core IMS. 

(6) The Core IMS forwards the Session Termination Confirm to the SCF. 

(7) The SCF forwards the Session Termination Confirm to the MF that releases all resources associated with the 
session. 

8.5 Network PVR service procedures 

Network PVR (N-PVR) service is used by the UE to ask for a capture of live content by the network and to access it 
later on. 

The N-PVR service procedures comprise two major steps: 

Step 1: Request for N-PVR Service Capture Request. 
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The UE sends an N-PVR content capture request to the SCF. This request can be: 

• an impulsive request: in this case, a BC service is already activated. The UE asks the SCF to record the Hve 
content currently being watched. This may be a request to record current Broadcast Programme or a sequence 
of programmes from a given position in time (BC bookmark) .This is as discussed in clause 8.5.1.1. 

• an off-line request: the UE asks the SCF to record a particular live content unrelated to any active BC session. 
This may be a request to record current Broadcast Programme or a sequence of programmes from a given 
position in time (BC bookmark). This is as discussed in clause 8.5.1.2. 

Step 2: Request for N-PVR service. 

Once recorded, the user can make a request for previously recorded N-PVR request. The N-PVR content can be 
resumed on the same UE or different UE belonging to user from start or from the point at which the content recording 
was requested. 

NOTE: The case when an N-PVR service capture is done as an impulsive request and is requested later from the 
same or another UE from the point at which the content recording was requested can be viewed as a case 
of "Park and Pickup TV" as described in clause 3. 1 . In this case, the currently active Broadcast TV 
programme or channel that was scheduled for an impulsive N-PVR capture request can be requested at a 
later point on the same or different UE from the previously paused/parked point. 

8.5.1 Signalling Flows for Network-PVR Service Capture Request 

This can be handled as an off-line request or as an impulsive request. 

8.5.1.1 Signalling Flows for Network-PVR Using Impulsive Request 

Figure 32 depicts the typical steps that occur when the UE makes an impulsive request for an N-PVR service. 
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Figure 32: N- PVR capture using impulsive request 

Specifics of interaction with RACS have been removed for purpose of simplification. It will follow the same procedures 
as outlined in the BroadcastTV and COD flows in clauses 8.3 and 8.4. 

(I) UE initiates Broadcast TV session following procedures specified in clause 8.3.1. 



£75/ 



49 



ETSI TS 182 027 V2.4.1 (2009-07) 



(2) The user (on UE) makes a request to the SCF through the core IMS to capture the currently watched Hve 
content. During this step, the UE gives appropriate parameters to the SCF to identify the content to be recorded 
(e.g. BC service id and or current BC ProgrammelD, time channel delimitation code, beginning_date, 
end_date, duration, etc.). 

NOTE: The SCF may check the N-PVR max-duration parameter to decide whether to allow the user to capture 

the selected live content. Instead of specifying a time limit, the UE may specify the current ProgrammelD 
indicating that the current Broadcast programme needs to be captured. The SCF answers with a N-PVR 
content capture response indicating to the user if capture of the content is allowed or not. 

(3) The SCF records the N-PVR/BC bookmark information as part of the IPTV service action data. The SCF then 
follows relevant procedures to initiate the recording of the content by the N-PVR-MF, details of which are not 
explicitly shown in figure 32. 

(4) The UE initiates Broadcast session termination procedures as defined in 8.3.3. Depending on the usage model, 
the UE initiates the Broadcast session termination procedure immediately after issuing the N-PVR capture 
request or it may do it at later point. The former would be the typically be the case of "Park and Pickup TV". 

8.5.1 .2 Signalling flows for the Network-PVR off-line capture request 

Figure 33 depicts the typical steps that occur when the UE makes an offline request for a N-PVR service. 
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Figure 33: N- PVR Capture procedures using offline request 

(1) The user (on UE) makes a request to the SCF through the core-IMS to capture a particular live content. During 
this step, the UE gives appropriate parameters to the SCF to identify the content to be recorded (e.g. BC 
service id, BC programmelD time channel delimitation code, beginning_date, end_date, duration, etc.). 

The SCF may check the N-PVR max-duration parameter to decide whether to allow the user to capture the selected hve 
content. 

NOTE: The content capture request may go to the SSF instead of the SCF. This implies that the SSF needs to 

communicate with the SCF. A reference point for direct communication between the SSF and SCF is out 
of scope for this release. 

(2) The SCF follows relevant procedures to initiate the recording of the content by the N-PVR-MF. 

8.5.2 Signalling flows for Network-PVR content session 

Figure 34 depicts the typical steps that occur when the UE makes a request to retrieve/resume previously recorded 
N-PVR content. 
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Figure 34 

(1) The SSF presents the UE with listing of available N-PVR Broadcast TV content captured via impulsive or 
offline capture requests, from which the user can select. In addition the "BC bookmark" information could be 
presented by the SSF else the UE can make a separate request to retrieve it from the SCF as specified in 
step (3). 

(2) The UE initiates an N-PVR session. The N-PVR session is equivalent to the CoD session. Therefore 
procedures defined in clause 8.4.1 apply. 

(3) The UE may request to the SCF through the core-IMS BC bookmark information pertaining to the Broadcast 
TV programme(s) that was previously requested to be recorded. 

NOTE 1: Instead of having the UE retrieve the BC bookmark information as in Step (1) or (3), it may be possible 

for SCF to directly send the BC bookmark information from IPTV service action data to the MCF. Details 
of the procedures are out of scope for this release. 

NOTE 2: This is a logical step. For efficiency purposes it may be combined with step (2). 

(4) The UE makes a request to play the content from specified bookmarked location. 

(5) This includes procedures for trick play control of the resumed BroadcastTV stream. 

(6) When the UE wishes to modify to terminate the resumed BC programme, it follows session termination 
procedures as specified in clauses 8.4.2 and 8.4.3. 
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8.6 Time Shift service procedures 



The Time Shift service is used by the UE to view a programme that has already occurred or started. It is necessary for 
the IPTV operator to store a programme in order for this service to be available. Note that unlike N-PVR it is not 
necessary for a UE to indicate that a programme shall be recorded but it is not always the case that a programme is 
Time Shift enabled. The time to live for Time Shifted enabled programmes have a different expiration time compared to 
N-PVR (example 1 week compared to possible 6 months for N-PVR). For a programme that has not finished it is 
possible that the UE catches up with the broadcasted programme sent in real time. 

The user selects timeshift content from the information provided by the SSF; just as any other CoD content. 
Consequently initiation and termination of time-shift sessions are exactly the same as for CoD, as described in 
clauses 8.4.1 and 8.4.3 respectively. 

Modification of the session is also the same as for the CoD service, as described in clause 8.4.2, except for the special 
case when the timeshift session catches up with real time, at which time the session may be modified to switch over to 
multicast. In this case the same flows as for trickplay TV will be used. 



Presence and IPTV 



IPTV services may be combined with the presence service capability. This clause describes the mechanisms that apply 
when IPTV services are combined with the presence service capability. 

These mechanisms may also be used for other purposes then publishing user presence information. For example they 
may be used to gather statistics about BC TV Service or user behaviour information. 

9.1 Presence architecture and functional description 

The architecture and functional description of the presence service capability when used in relation to the IPTV services 
conform to TS 182 008 [10]. 

9.2 Presence attributes for IPTV 

The Presence attributes defined in TS 182 008 [10] apply. 

In addition, the following specific IPTV attributes shall be supported: 

• BC service activated; 

• CoD service activated; 

• PVR service activated. 

If the IPTV presence attribute "channel currently accessed" is supported, then the machine-readable part of the 
identification of the channel shall be globally unique. The term globally unique here means that there is no ambiguity in 
the identification of the channel if presentity and watcher (for terminology, see in TS 182 008 [10]) are with different 
network operators and/or in different countries. 

The following specific IPTV attributes may also be supported: 

• BC TV Service currently accessed; 

• programme currently watched, when available; 

• content currently accessed. 

It is up to user's decision to include specific IPTV attributes in his/her presence information. 

When the "BC service activated" attribute is included in a presence document, the attributes "BC TV Service currently 
accessed" and "programme currently watched" may also be included, depending on user preferences. These attributes 
shall not be present in a document if the "BC service activated" attribute is not present. 
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When the "CoD service activated" or the "PVR service activated" attribute is included in a presence document, the 
attribute "content currently accessed" may also be included depending on user preferences. This attribute shall not be 
present if the "CoD service activated" or the "PVR service activated attribute" is not present. 

9.3 SIP related procedure 

The SIP related procedures defined in ES 283 030 [13] apply. 
The publication of CoD related presence information happens: 

• after completion of CoD session initiation procedure; 

• after completion of CoD session termination procedure. 
The publication of BC related presence information happens: 

• after completion of BC session initiation procedure; 

• after completion of the BC session termination procedure; 

• optionally, when the UE successfully subscribes to a particular multicast channel (i.e. channel hopping). 

In order to cope with overload possibly caused by numerous channel-hopping, it shall be possible to define a timer set 
up to limit the number of publications. This timer is started and reinitialized after each channel change. Publication shall 
only be sent when the timer elapses. 



10 Security 



10.1 Authentication 

Authentication procedures for the Ut reference point conforms to TS 187 003 [5]. 

10.2 Content Security 

The locations and related reference points of the following elementary functions are defined in TS 187 003 [5]. They 
are reproduced below for information. 

For content security the following elementary functions are used: 

• Content licensing: This elementary function handles the licenses issuing related functions, including 
generation and distribution of the licenses to the desired entities. 

• Key management: This elementary function handles the management of the security keys, including generate 
and provide the keys and corresponding parameters to the desired entities. 

• Content encryption: This elementary function handles the content protection related operations, e.g. content 
encryption and encapsulation operations, etc. 

These three elementary functions may be flexibly located in existing functional entities or new ones as a whole or in 
independent parts. 

NOTE: Some of these elementary functions may be executed on-line (in real-time) or off-line (in this case could 
be part of the management). 



1 1 Charging 

IMS charging principles apply as defined in ES 282 010 [i.2]. 
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12 Management 

12.1 Management requirements 

For each IPTV service, several entities require to be provisioned with necessary network parameters (e.g. muhicast 
addresses for multicast services, source of original content, etc.) and to associate specific content or service with these 
network parameters. These entities are: 

• the SSF, as it needs to provide the UE with the content identifier associated to an IPTV service and possibly 
with a set of network parameters (control and/or content channel descriptions) necessary to initiate an IPTV 

session; 

• the MPs, as they need to associate a content identifier with multicast or unicast streams to be delivered to the 

UE; 

• the SCF, as it may also need to provide the UE with network parameters in response to service initiation 
requests, in configurations where the SSF does not provide this information beforehand. 

Consistent information has to be provisioned on these entities. 



12.2 Content management 



Content management functionalities are responsible for managing acquisition of content and service information 
(e.g. metadata) from sources, controlling validation and/or processing/adaptation to the required format and also to 
provide management functionalities for supporting distribution of content to the media delivery function. 

NOTE: Content management is used in the case of offline or online ingest of the content. The online ingest means 
receiving content directly streamed from the content provider. The offline ingest refers to content files 
delivered by other means than the online (e.g. such on physical media like DVD, CD, etc.). The content 
management is used by the IPTV service provider to statically provision the content. 

Content management functionalities can consist of the following groups of elementary functions: 

• Content acquisition - responsible for content management functionalities needed to acquire, aggregate and 
import content/metadata from multiple external sources. 

• Content validation/adaptation - after acquisition it could be necessary to manage content/metadata format 
validation and verification as well as to define a relation between content and its metadata. Management can 
also control media or metadata adaptation and/or processing to the required type of media files or streams. 

• Content distribution - management functionalities for distribution of content and its metadata to appropriate 
functional entity (e.g. media files storage in MDF). This function handles the whole lifecycle of the content 
and provide management support for its distribution to media delivery distributed architecture (e.g. uploads on 
video streamers, moving according to management criteria such as popularity, regionalization, un-referenced 
content, MDF resources and so on). 



1 3 Support of Metadata 
13.1 Introduction 

IPTV Metadata enriches the service experience of the IPTV Services a user has access to. IPTV Metadata may originate 
from the User, the NGN Service Provider, the Application Provider or the Content Provider. The Metadata should be 
processed, filtered and enriched by involved IPTV solution entities in order to improve the user experience. 

NOTE 1 : Processing, Filtering and Enriching Metadata may be based on techniques like personal preferences, 
additional subscribed-to services and other means and are out of scope of the present document. 

NOTE 2: How user originated Metadata is injected into the IPTV solution is out of scope of the present document. 
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The access to Metadata may be considered as a service in itself which shall be protected by appropriate service 
authorization means before the Metadata is delivered to the UE. 

13.2 SSF support 

IPTV Metadata may be delivered outside of an IPTV service session by the SSF. 
Xa shall be used for the Metadata delivery. 



13.3 SCF/MF support 



IPTV Metadata may be delivered as part of a normal IPTV service session or inside an IPTV service session dedicated 
to Metadata delivery. In the first case, the Metadata is sent in addition to Media as part of the IPTV session. In either 
case the Metadata capabilities are negotiated during session setup or session modification between UE and SCF. The 
Metadata itself is delivered via the MDF through unicast or multicast via Xd. 
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Annex A (informative): 

Integration of non-SIP-AS Service Discovery Function in 

IIVIS based IPTV 



A.1 Introduction 



Clause 5 defines Service Discovery and Selection (SD and S) as a two step process consisting of Service Discovery and 
Service Selection. While clause 5 focuses on discovering services by an SIP based SDF entity, the Service Selection 
uses non-SIP mechanisms. This annex describes using non-SIP SDF to reuse standard non-SIP Service Discovery 
technologies such as DVB-IP Service Discovery as specified in TS 102 034 [6]. 



A.2 Architecture 
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Figure A.I : Functional architecture for IPTV services integrating non-SIP SDF 



A.2.1 Functional entities 

Figure A. 1 depicts the IMS based IPTV architecture based on figure A.2 using a non-SIP AS SDF for Service 
Discovery. All entities are defined in clause 5. 
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A.2.2 Reference points 



Figure A.l depicts the IMS based IPTV architecture based on figure A.2 using a non-SIP AS SDF for Service 
Discovery. All shown reference points are defined in clause 6 except Xa' which is described in clause A.2.2. 1. 



A.2.2.1 UE-SDF(Xa') 

This reference point delivers Service Discovery Information, i.e. SSF addresses in the form of URIs and/or ip-address, 
from the SDF to the UE. Both Unicast and Multicast delivery of this information is possible. 

The use of Xa' conforms to TS 102 034 [6] clause 5.2.5, where the term "HNED" is to be replaced by "UE" and where 
"Location(s)" carries the SSF address(es). 

A.2.3 Procedures 

A.2. 3.1 IPTV service attacinment and selection 

Figure A.2 defines steps 3 and 4 of figure 9 in case the SDF is not SIP- AS based. 
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Figure A.2: IPTV service attachiment and selection 

(1) The UE requests the SDF it was assigned. This assignment may have occurred during the network attachment 
phase, during offline provisioning or by other means. 

(2) The SDF determines the proper SSF (or SSFs). It is for further study how the SDF may take into account the 
UE's capabilities, the user's profile and/or the location of the UE (Personalized Service Discovery). 

(3) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

(4) The UE requests the SSF to get the selection data. 

(5) The SSF delivers the requested data to the UE. 

NOTE: If a non-SIP AS SDF is used for IPTV service attachment, no IMS registration prior to step (1) of 

figure A.2 is required. Therefore, step 2 of figure 9 (IMS registration) can occur in parallel to, before or 
after the procedure described in figure A.2. 
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